Spreadsheet software, such as MICROSOFT's EXCEL software, operates to simulate paper spreadsheets, also sometimes called worksheets, or workbooks, in which columns of numbers are operated upon mathematically, e.g., summed, multiplied, etc., for budgets, plans, models and other tasks. A typically spreadsheet software user interface appears on screen as a matrix of rows and columns, the intersections of which are called “cells.” The cells can be filled with labels, numeric values or formulas. Labels are descriptive text such as “Rent” and “Gross Sales.” Values are the actual numeric data, and formulas command the spreadsheet to perform specific calculations based on the values; for example, the formula SUM CELLS A5 TO A10, may cause the spreadsheet software to sum the cells found at column A, rows 5 to 10. Formulas allow interrelationships of cells, and they are easy to create. For instance, one may merely point to a cell and click, and then press a key (+, −, etc.) of any arithmetic operation intended to affect the cell. For example, the creation of a formula might be “the contents of this cell PLUS the contents of this cell DIVIDED BY the contents of the next cell over to the left.”
After numbers are added or changed, the formulas generally recalculate the data automatically or at the initiation of the user, e.g., with the press of a key. This can create a recalculation “ripple” effect throughout multiple cells. Since the contents of any cell can be calculated with or copied to any other cell, a total of one column can be used as a detail item in another column. For example, the total from a column of expense items can be carried over to a summary column showing all expenses. If the contents of a cell in the detail column changes, its column total changes, which is then copied to the summary column, and the summary total changes.
A powerful tool for bankers, stock brokers, economists, and the like, such a ripple effect lets a user create a plan or model, plug in different assumptions about the model, i.e., change parameters, and immediately see the impact on the bottom line. This “what if?” capability makes the spreadsheet indispensable for budgets, plans and other equation-based tasks. The “what if?” capability thus allows users to change underlying parameters, such as interest rate, of a mathematical model, such as growth of bank account over time. The “what if?” similarly allows a user to change underlying facts, such as starting bank account balance, the formulas interrelating the cells, such as calculating interest with or without a formula that compounds interest, and even the names of the cells to address different mathematical scenarios.
Thus, currently, any information concerning the cells of a spreadsheet can be altered by the user, so that the user can see how the alteration plays out in the overall model. However, the reality is that generally, once a model is set up, certain aspects of the model are not intended for change. For instance, it may be known by the user, in the above-described growth example, that the starting bank account balance is $2000, and that such fact will not change. Accordingly, it would seem an unnecessary capability of the spreadsheet that such fact could be altered. Similarly, the cells with the labels in them, while alterable, do not change the result of the growth formula calculation, i.e., whether a certain column or value is labeled “growth rate” or “interest rate” is not relevant to the underlying formulas. It seems difficult, therefore, to distinguish under the current spreadsheet model, between cells intended as parameters for tweaking under different assumptions, and those intended as unalterable fixtures, or given parts of the model.
This tends to be well and fine for the creator of the spreadsheet at issue, because the creator generally remembers which the relevant parameters are for tweaking. However, as soon as a third party user unrelated to its creation views the spreadsheet and the model it represents, that third party user will have to undergo a difficult exercise of ascertaining which cells were intended as parameters, and which were not. Such third party user may not know, for instance, that a $2000 starting balance is a given part of the model. Moreover, as a mathematical model becomes less trivial than the growth example given herein, even the creator of the model may have difficulty remembering which parts of the document are parameters, and which are not.
Accordingly, currently, a user of a spreadsheet cannot explicitly designate a cell of a spreadsheet as a parameter. For a similar reason, a user cannot discover which parts of the spreadsheet are parameters. And still further, for similar reasons, a user cannot alter or set parameters, as such, i.e., as distinguished from parts of the model that are not parameters. These deficiencies associated with parameters of spreadsheet documents described remain unaddressed in the art.
Furthermore, historically, spreadsheets have been standalone applications, wherein a user is co-located with a local computer having a processor executing the spreadsheet software installed on the local computer, such as might be the case for any of the above-described scenarios.
With the advent and explosion of the Internet, however, computer users have grown accustomed to conveniently accessing virtually any kind of electronic document from virtually any location. In particular, the proliferation of the World Wide Web (the “Web”) and Web browser application programs has made accessing many kinds of documents, such as text and graphics documents, very convenient. Through a Web browser application program, a user can access and view many types of electronic documents without the need for any additional software, including spreadsheet documents.
Thus, for instance, a user can create a spreadsheet document on a local machine, “publish” [that spreadsheet document to a server, from which any authorized user can view the spreadsheet document via a Web browser. When rendered in the Web browser, the spreadsheet is displayed in a manner that is substantially similar to the spreadsheet when displayed by a spreadsheet application program. However, currently, similar to the above-described client application deficiencies, users cannot designate any cells as parameters when creating a spreadsheet document for display on a Web browser either. For similar reasons, users cannot discover which parameters apply to the spreadsheet and cannot set or alter those parameters.
Accordingly, it is not currently possible for users to lockdown a model in a spreadsheet and make only certain cells editable. These cells in effect are the “function” parameters that can be changed. The spreadsheet model represents the function or functions. While there currently is a way to lockdown a spreadsheet and make only certain cells editable, this is a user interface (UI) driven lockdown wherein there is no mechanism to explicitly designate certain cells as the parameters to a spreadsheet, or to have that mechanism track cells moving and the workbook changing. Since there is no way to designate cells as parameters, there is also no way to call a spreadsheet to query for the available parameters to the spreadsheet. Furthermore, in the case of existing spreadsheet server products, it is not yet possible to edit cells at all. These and other problems of spreadsheet functionality described herein leave unaddressed problems in the art.